Skip to content

Answer a few questions from developers - #461

Open
NicNomadic wants to merge 1 commit into
mainfrom
answer-devs
Open

Answer a few questions from developers#461
NicNomadic wants to merge 1 commit into
mainfrom
answer-devs

Conversation

@NicNomadic

@NicNomadic NicNomadic commented Sep 9, 2026

Copy link
Copy Markdown
Collaborator

We received the following legitimate questions from some developers using the Tezos X features in Etherlink 7.x:

Q1 — Out-of-gas on the far side of a NAC call. The documentation covers revert propagation, but not out-of-gas specifically. Is an OOG inside the callee runtime surfaced to the caller as an ordinary catchable failure, with the same rollback guarantees? Our non-custody argument depends on "burn and release cannot be separated" holding under every failure mode, including gas exhaustion mid-way.

  • add short answer: explanation for OOG catching for EVM->Michelson calls
  • We might want to expand on what we mean by Atomicity and what are the provided guarantees, maybe provide high-level examples to illustrate ? It's quite important and maybe deserve a bit if yapping.

Q2 — Alias derivation: canonical formula and stability. The accounts & aliases page documents the EVM→Michelson alias as KT1(blake2b_160(raw 20-byte evm_address)), but on previewnet we observe that the implementation hashes the lowercase 0x… string instead: KT1(blake2b_160(utf8(lowercase("0x…")))). Our wiring uses the empirically verified formula. Which one is canonical? And more broadly: are alias derivations committed to being stable across protocol/kernel upgrades? Our wiring is deliberately immutable, so an alias-derivation change would permanently brick both bridges.

Q3 — Gas guidance for cross-interface calls. What is the recommended practice for a contract like ours — forward all remaining gas to callMichelson, or cap as we do? Is the conversion coefficient a protocol constant we can size the cap against, and can the Michelson-side budget ever be insufficient in a way that does not surface as a revert? Relatedly, wallet-side gas estimators only see one runtime, so cross-interface transactions need manually raised limits today (~200k for a wrapped ERC-721 transfer) — is estimator support planned?

  • first part is also answered by the short answer to Q1 (see above)
  • eth_estimateGas does take the Michelson runtime into account, so maybe there is a workaround here, not sure it's super satisfactory though (not only related to doc)

Q4 — The Michelson gateway's %call entrypoint. Besides call_evm, the gateway exposes a %call entrypoint (pair string (list (pair string string)) bytes nat option) whose semantics we could not determine — five plausible encodings all produced an opaque tezlink_error. Not blocking (call_evm suffices), but documentation would help.

  • Do we want to document the low-level %call?

@vercel

vercel Bot commented Sep 9, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated
docs-etherlink Ready Ready Preview Sep 9, 2026 1:16pm UTC

Request Review

@NicNomadic
NicNomadic marked this pull request as draft September 9, 2026 13:41

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(not specifically related to this file)
@pecornilleau do you want to expand on what we me an by Atomicity and what are the provided guarantees? Can you specify what kind of high-level examples may illustrate this?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(not specifically related to this file)

Do we want to document the low-level %call, knowing that it requires one to know and deal with low-level details -- are they guaranteed to be stable in the future? Does it allow to do useful things users cannot do with the higher-level entrypoints (%call_evm)?

@NicNomadic
NicNomadic marked this pull request as ready for review September 9, 2026 13:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant